Operational Experience Sharing: Comparing The Pros And Cons Of Singapore’s Cn2 Among Different Operators

1.

overview: what is cn2 and its significance in singapore

cn2 is the second-generation backbone network launched by china telecom. it has branches such as gia and ctg for international interconnection; nodes in singapore are usually used to connect mainland china and southeast asia/global traffic.
small segment: 1) cn2 advantages: more stable international exports, shorter jitter and packet loss, better qos strategy; 2) importance in singapore: geographically close to major ixs in asia, can be used as a transit point; 3) applicable scenarios: cross-border real-time business (games, video conferencing, financial quotes).

2.

explanation of common line types and terminology (understanding in practice)

explain common terms to help you avoid being confused by terminology when communicating with operators.
small segments: 1) cn2 gia: globally optimized and with high priority; 2) cn2 gt/ctg: more biased towards telecom internal interconnection or specific backbone paths; 3) mpls/dedicated line/vpn: different bearer methods will determine sla and packet loss characteristics.

3.

common operators and comparison frameworks in singapore

common candidates are listed: china telecom, china unicom, china mobile, and local transit/ix providers (equinix, singtel, starhub, megafon/ntt, etc.).
small segments: 1) telecom (cn2 direct connection/self-operated backbone): excellent delay and jitter; 2) china unicom (possibly connected to cn2 through dedicated lines): different cost performance; 3) local operator transit: flexible but pay attention to routing hop count and sla.

4.

preparatory work before purchasing (listing)

list the information that must be gathered before requesting a quote from a supplier and signing a contract.
small segments: 1) clarify business requirements: bandwidth, concurrency, whether ipv6 is required, and whether fixed asn or bgp is required; 2) test point selection: at least 3 test ends from the client side, hong kong/singapore and china; 3) sla elements: packet loss threshold, delay, failure recovery time and compensation terms.

5.

how to request sample routes and test accounts from operators (step by step)

operation steps to ensure a true comparison.
small subsections: 1) put forward requirements: write an email or work order, requesting a test ip (at least 2 different egress ips are required), and requesting the neighbor as and egress pop location; 2) obtain traceroute and bgp path examples: request to submit a traceroute export from singapore to the core node in mainland china; 3) request a bandwidth test account or provide iperf3 service parameters.

6.

preparing the local network before deployment (access point setup)

engineering practice steps to ensure smooth access.
small segmentation: 1) hardware and interface: confirm that the switch/router supports the required rate and mtu (usually 9000 depends on the operator); 2) physical connection: prepare the optical fiber module (sfp/sfp+ specification) and confirm the link speed with the computer room; 3) ip planning: pre-allocate the management network segment, bgp peering ip and acl policy.

7.

bgp peer establishment and route announcement (for customers with bgp needs)

practical steps (from high-level to executable command ideas).
small segment: 1) prepare information: asn, prefix to be announced, neighbor ip; 2) establish peering: configure neighbor and set password, retention time, and maximum number of prefixes after both parties agree; 3) routing policy: set prefix filtering, community marking, med/local-pref policy to affect the inbound and outbound route priority (example: set cn2 priority to a higher local-pref); 4) verification: use bgp table, show ip bgp neighbors, check whether the route is received by the peer.

8.

link test process (specific commands and steps)

a set of reproducible test procedures is given to facilitate comparison between different operators.
small segment: 1) basic test: ping target ip (record min/avg/max & packet loss); 2) route tracing: traceroute or mtr (record the number of hops and which hop the packet loss occurs); 3) bandwidth test: use iperf3 (one-way and two-way) and test in different time periods (peak/valley); 4) long-term monitoring: deploy smokeping or prometheus+blackbox the exporter does 7×24 delay and packet loss trends.

9.

practical comparison suggestions: how to compare the pros and cons of each operator

standardize test results to facilitate decision-making.
small segment: 1) indicator definition: average delay, 95th percentile delay, packet loss rate, jitter, mttr; 2) comparison method: same time period, multi-node parallel test; 3) weight recommendation: real-time business is biased towards delay/jitter (weight 70%), large traffic transmission pays attention to stable bandwidth (weight 30%); 4) cost consideration: not only the bandwidth price, but also sla, support response speed and out-of-band management.

10.

frequently asked questions and troubleshooting steps (operation and maintenance manual style)

step-by-step troubleshooting process for common situations.
small segments: 1) high latency: first check the local link (interface error count, packet loss), and then use mtr to locate which hops are experiencing packet loss; 2) intermittent packet loss: check the device cpu/queue to see if there is bgp refresh or link jitter; 3) poor routing: check the bgp policy and whether the peer has assigned a low-priority community, and communicate with the peer operation and maintenance to make adjustments if necessary.

11.

optimization suggestions (commonly used adjustments on singapore’s cn2 line)

practical optimization strategies that can be implemented.
small segments: 1) route priority adjustment: use local-pref or as_path prepend to affect outbound; 2) qos and queue management: classify different services at the edge and set up queues; 3) multi-line and intelligent scheduling: configure sd-wan or bgp multi-path, and set health detection and automatic switching policies.

12.

key points for negotiating contract and sla details

what procurement and legal affairs should pay attention to.
small subsections: 1) clarify sla indicators: packet loss, delay, availability and compensation mechanism; 2) fault definition and notification: it is required that fault work orders must include timeline and root cause analysis (rca); 3) change and maintenance window: clear agreement on advance notification period and maintenance impact scope.

13.

monitoring and alarm establishment (implementation steps)

how to establish a continuous monitoring and alarm system for cn2 lines.
small segments: 1) indicator collection: delay, packet loss, bandwidth utilization, bgp status; 2) tool recommendations: prometheus+grafana, zabbix, thousandeyes or ripe atlas for cross-point observation; 3) alarm strategy: set thresholds and hierarchical alarms, and connect alarms to the operation and maintenance platform (webhook/pagerduty/dingtalk).

14.

summary and decision-making suggestions (quick conclusions for procurement and operation and maintenance)

convert comparison results into executable decision-making processes.
small segments: 1) priority selection: for real-time services, cn2 gia direct connection is preferred; 2) when budget is limited: evaluate local intermediaries and conduct strict testing; 3) continuous evaluation: run parallel tests at least 1 month after signing the contract to confirm whether the standards are met before full migration.

15.

q: which operator has the best latency when using cn2 in singapore?

answer: generally, china telecom's self-operated cn2 gia in singapore has the most stable latency and jitter performance when exporting to mainland china. however, the actual results will vary depending on the specific pop location and peer access. it is recommended to compare the real data of the current candidates through the above test process (multi-point parallel ping/mtr/iperf) before making a decision.

16.

q: what should i do if it is discovered that the route passes through a non-cn2 path?

answer: first use traceroute to confirm the hop point and collect evidence (timestamp, packet loss point); then communicate with the supplier and ask to check the bgp neighbor table and routing policy. if necessary, request the peer to establish a community on its backbone or adjust med/local-pref; if the other party has no repair plan, consider replacing or adding backup lines.

17.

q: how to continuously verify whether the sla is up to standard after signing the contract?

answer: establish 7×24 monitoring (prometheus/thousandeyes, etc.) and save historical data, and calculate the 95th percentile delay and packet loss rate on a monthly basis; if the sla is not up to standard, first communicate with the supplier to ask for rca and perform compensation according to the contract. if the sla is not met, consider re-evaluating the contract or switching suppliers.